網路或是文件資料收集後，可能有pdf，xls，網頁html，或是部份文字，圖檔...等，通常還要再加工幾次才能餵給系統用。但在應用規格未定前，很難直接定義正規化的欄位，定多了阿雜（有人覺得這階段不用，useless就通通不准），定少了彈性又可能不夠（雛型demo後，客戶長官每看一次，就多一堆的需求...）。為了保留資料的最大彈性，我會先把不同來源，不同格式的原始資料統一轉成JSON的型態保存。

JSON 詳細說明請見wiki：https://zh.wikipedia.org/zh-tw/JSON

我覺得JSON在人眼的可讀性介於原文與XLS之間，不過熟悉這種物件結構，加上有合適的Viewer通常不會有太大困難。而對於程式或是在一開始當UI prototype假API資料來源 （JSON原本就是出自JS的物件結構應用）很方便。

原始資料本身用JSON的好處還有，不用一開始就進入名詞定義這種燒腦的問題，可以等應用分析（SA階段）後，再從中截取轉換所需要的輸出格式（export XLS或轉進DB），或是後續想做不同面向的應用還是都可以再使用。

no SQL的相關應用技術也是基於JSON。而這邊偷偷推一下 Postgresql 資料庫，他從 9.2 版開始就有 json 的物件形態與查詢應用，而9.2版是在 2012 就推出的，在當年可是先鋒呢，有傳統關聯式資料庫的高效能，也可以有JSON的應用彈性，發展了十年也是相當的穩定可用。

遙想古早？！的年代，還是xml的天下，API差點被SOAP、WSDL、XSD攻下（wiki： https://en.wikipedia.org/wiki/SOAP ）。而當年不少自幹型的系統，還都會給不標準的XML內容，最常見就是跳脫字元不正確，像屬於資料內的url參數&很多都不跳脫，Lib怎麼吃怎麼吐，還要先幫原資料加工才能再處理。還好json撐過來了，這樣大家都輕鬆的多。

而資料結構的簡化表示法，近代還有 YAML （wiki： https://zh.wikipedia.org/zh-tw/YAML ），用於設定檔是也還蠻簡潔的，若要編寫的話，我會比較傾向在少量資訊，或當設定檔方面來使用。在開發過程中，常常需要人工調整內容資訊，或是做sample，人工寫yaml，若是大量的資料就會有強迫症，整天debug數空白就飽了。

總之目前JSON應該還是非結構化資料的首選，希望他可以撐久一點！